…en fix

Updates rust-lightning rev to include moneydevkit/rust-lightning#9:
trigger OpenChannel at peer_connected even during reestablish, fixing
stuck HTLC loop when existing channel capacity is insufficient.

…en fix (#13)

Updates rust-lightning rev to include moneydevkit/rust-lightning#9:
trigger OpenChannel at peer_connected even during reestablish, fixing
stuck HTLC loop when existing channel capacity is insufficient.

Channel usability (is_usable) was checked at four separate points:
htlc_intercepted, peer_connected, process_pending_htlcs, and
calculate_htlc_actions_for_peer. Each had its own deferral logic,
and they had to coordinate (the timer skipped channel opens
assuming peer_connected already handled them). This coordination
broke: PR #9 made peer_connected call process_htlcs_for_peer
during reestablish, which saw an empty capacity map because
non-usable channels were filtered out, and emitted a spurious
OpenChannel on every reconnect with a pending HTLC.

Move the usability check to execute_htlc_actions, right before
forward_intercepted_htlc. If no usable channel exists, the
forward is skipped and the HTLC stays in store for the timer to
retry. htlc_intercepted, peer_connected, and process_pending_htlcs
now all call process_htlcs_for_peer unconditionally.

calculate_htlc_actions_for_peer includes all channels in the
capacity map regardless of is_usable, so it correctly sees that a
reestablishing channel has sufficient capacity and does not request
a spurious new channel.

Change the pre-forward guard from is_peer_connected to
has_usable_channel, which covers the disconnect+reconnect race
where the peer is connected but the channel has not finished
reestablishing.